Sizing mySAP Business Intelligence
Most BI sizings relate in
some way to SAP’s Business Information Warehouse. Before specific CPU,
RAM, and other hardware-specific metrics can be nailed down, it’s
helpful to understand the primary architectures employed for BW systems,
such as
Three-Tiered
Architectures, where the operational systems (like R/3) feed
consolidated data to an enterprise warehouse, whereas smaller data marts
are stocked with summary data. This is the most time-consuming and
expensive BI solution to implement.
Two-Tiered
Architectures, where the operational systems feed only an Enterprise
Data Warehouse. This normally results in a faster implementation than
otherwise possible, sacrificing potential scalability of the BI solution
in favor of ease of implementation.
Two-Tiered
Architectures, where the operational systems feed one or more
functionally specific (that is, SD, MM, FI, or APO, and so on)
Independent Data Marts. This is the most common two-tiered
implementation, as it allows an IT organization the chance to support
granular departmentalization of popular functional data and queries.
Further, this is often at the expense of a dedicated repository for
extracted, cleaned, and transformed detailed data.
Beyond the core
release version and underlying architecture, a number of key sizing
factors exist for BW, like the adoption of a SAP BW Persistent Staging
Area (PSA) and general Operational Data Store (ODS). Both of these
affect the database size and performance characteristics
of the SAP BW system as well as the speed and additional system load of
the operational systems during the data extraction window.
Persistent
Staging Area (PSA)—This transparent table for storing detailed requests
in the original format of the transfer structure is actually nothing
more than another InfoSource. The source system maintains a key request
number, packet number, and record number.
Operational
Data Store (ODS)—The ODS provides a location for all raw operational
data to be combined and housed, before such data is extracted, cleaned,
and otherwise reformatted. It is often “persistent” too.
In the context of the
ODS, the PSA makes up the first level and the ODS table makes up the
second level of the ODS. Therefore, the first level consists of the
transaction data from the source system, and the second level consists
of the consolidated system’s raw data, as well as data from several
source systems and InfoSources.
With this information in
mind, we can now turn our attention to identifying the sizing questions
that the SAP Quick Sizer needs to have answered:
Three different types of users, classified by the frequency of their activity and the reporting performed. Frequency is measured in navigation steps per hour, one of which is equivalent to nine SD dialog steps. Users include information (low or normal users), executive (or advanced users), and power users, executing 1, 11, and 33 navigation steps per hour, respectively.
Three different types of queries.
Information users spend 80% of their time viewing reports and 20%
performing OLAP analysis. Executive users split their time evenly
between reporting and OLAP analysis. Power users, on the other hand,
execute intensive data exploration activities 100% of the time. With knowledge of the user types and their activity breakdown, it is possible to estimate CPU and memory requirements.
Number and types of InfoCubes,
which are the objects within BW upon which reporting and analysis is
performed. SAP BW ships with standard preconfigured InfoCubes, which can
be described by attributes like dimensions, key figures, and
length—with this kind of data, a sizing engineer can begin to calculate
roughly how large your SAP BW database will be.
Number of periods, or the amount of time measured in weeks that you want to keep a particular set of data.
Sizing BW is a
challenge, to say the least; the aforementioned questions and data being
collected are valuable in the hands of an experienced BW consultant,
but can easily be misinterpreted otherwise. And because one of the major
concerns in sizing BW relates to determining how big your BW database
will initially be, and how quickly it will grow, experience with BW
beyond simply sizing will make a huge difference in how close you come
to sizing a useful mySAP BI solution.
Rules of Thumb for Sizing mySAP CRM
In addition to
documenting and understanding the business scenarios that drive sizing
the mySAP CRM server, sizing CRM can involve any or all of the following
special-function servers as well:
The InQMy Application Server
provides an execution environment supporting Internet Sales
business-to-consumer and business-to-business processes, implemented via
Java Server Pages (JSPs). This takes the place of the SAP Internet
Transaction Server (ITS) found in the earliest versions of SAP CRM.
The TRex Server
(Text Retrieval and Information Extraction) provides indexing and
search capabilities for information held outside of the SAP CRM
database, like catalog information or product documentation.
A Workgroup Server
acts as nothing more than a standard Microsoft SQL Server database
server. I suggest that you size this using a traditional database sizing
tool. In my experience, the end result for a “typical” Workgroup Server
equates to a system capable of hosting 100 transactions per minute for
every concurrent Mobile user expected on the SAP CRM system.
A Communication Station,
which acts as a gateway between front-end Mobile clients and the CRM
system, and was originally built on Microsoft’s DCOM product running
Microsoft Transaction Server (now based on Microsoft .Net technology).
Sizing the Communication Station is akin to determining the number of
active users who are connected to the system and simultaneously synchronizing their data between their client machines and the various data repositories maintained by mySAP CRM.
A Multi-Channel Interface Server,
which maintains the relationship between the CRM server and any CTI,
email, chat, and similar middleware/services. These are not
processor-intensive; something like a two-processor system with 1GB of
RAM and 36GB of disk space will meet most organizations’ requirements.
Of course, the CRM
Server is the “central” server of any SAP CRM solution, and can be
hosted on any number of UNIX and Windows platforms. Central to providing
this functionality is another server, the Internet Pricing Configurator
(IPC). The IPC runs only on a separate Windows 2000 server and is a
horizontally scalable Java application that provides pricing calculation
and product configuration capabilities. For sizing the IPC, I suggest
that you determine the peak number of orders received per hour, where it
is assumed that each order is composed of four line items and an
associated four images. Or, if only transaction data is available,
determine the peak number of objects created in the potentially heaviest
day of CRM processing. Next, it’s also important to determine and
characterize the number of various CRM users, such as the following:
CRM Internet Sales Users,
who are usually split into either browsing users (the majority) and
users who actually purchase goods. Browsing users tend to navigate the
site and catalog, gathering information about products. Thus, they
impact sizing the Web server component of CRM, but not the CRM server
itself. Users who actually purchase goods go through the process of
searching, and on top of this activity they eventually create and fill a
shopping cart and then proceed to purchase the goods.
Mobile Sales Users,
who spend their time uploading data to the CRM system a few hours each
day or so. For sizing purposes, the goal is to determine the greatest
number of users expected to access the system in the peak one-hour
period (usually in the very early morning or later in the evening, in my
experience).
Customer Interaction Center Users,
usually tasked with supporting telesales, telemarketing, and
service/support functions. Interestingly, these users not only place a
load on the CIC component of CRM, but by virtue of the work that they
perform, they also generate transaction and other loads across the rest
of the CRM system. Therefore, according to SAP’s Quick Sizer, these
users are actually counted twice—once as a CIC user, and once in their
respective business or functional area.
If details related to the
type of users have not yet been determined, but you still want to
estimate (for budgetary reasons, perhaps) what a CRM configuration might
consist
of, you can instead estimate the number of concurrent users expected on
the system during its peak period, using the following rules of thumb:
One concurrent low user equals 3 orders per hour
One concurrent medium user equals 30 orders per hour
One concurrent high user equals 90 orders per hour
Certain activities tend
to take place on the mySAP CRM system, too, which impact sizing. For
example, managing opportunities and activities, creating customer
orders, performing service-related transactions, and managing data
related to customers, products, and even projects consume CPU, memory,
and disk resources. It’s also important to estimate items like the
number of incoming and outgoing CIC calls handled per hour, the
retention period (measured in months, not weeks as is customary in other
mySAP solutions) of objects maintained in the CRM database before they
are archived or deleted, and the peak volume of objects (like sales
orders) created in a certain time period.
CRM is not an island unto
itself; it ties into many other mySAP solutions, especially your core
R/3 system. For example, each CRM sales order is eventually processed on
the R/3 system. I suggest employing traditional SD modeling to
determine this impact, using the SAP Quick Sizer and its SD-SLS type of
functional area.
SAP CRM can also touch
APO—availability requests are transferred between the CRM server and APO
system via SAP’s Remote Function Call (RFC) communication service. And
CRM’s Mobile Sales users can leverage SAP BW for reporting and limited
data mining; data is moved from BW to the SAP CRM server, and then
downloaded to your Mobile Sales user in the form of an Excel workbook.
Finally, sizing for the
CRM front-end clients (desktop and laptop interface devices, for
example) must be performed. Client requirements are uncomplicated, but
important. Three different user interfaces are available, but minimum
front-end requirements dictate a 350MHz processor, 256MB of RAM, and
about 30MB of free disk space, regardless of whether you employ the
standard SAPGUI or the newer JAVA or HTML-based interfaces. Note that
the addition of a mobile client bumps the minimum amount of RAM
significantly, though, to 512MB. Further, at least 500MB of free disk
space is required for mobile users.
Sizing Considerations for mySAP PLM
Product Lifecycle
Management (PLM) supports users responsible with managing product,
asset, and process information at any point in the product life cycle,
from selection and purchasing through production ramp-up, installation,
operation, engineering changes, maintenance/repair, retirement, and
more. From a sizing perspective,
you need to understand what exact functionality you will be
implementing. Choices are many, including the following:
Lifecycle Data Management
Asset Lifecycle Management
Program and Project Management
Lifecycle Collaboration
Quality Management
Environment, Health, and Safety (EHS)
PLM is closely linked
with SCM and CRM, and is implemented as an enterprise portal solution.
Like typical portal solutions, it facilitates communication and
collaboration between users; this activity must be quantified and fed
into sizing models. Until SAP includes mySAP PLM in the Quick Sizer, I
suggest that you approach this as a Portal sizing exercise, and work
closely with SAP AG and your hardware partner’s SAP Competency Center.
Supply Chain Management Sizing Considerations
Sizing SAP SCM
normally means focusing on SAP’s Advanced Planner and Optimizer
component. Hardware vendors require a lot of very detailed information
to even come close to sizing APO accurately. Questions about how you
will actually use APO need to be addressed first, including which APO
components you plan to implement. These include Demand Planning (DP),
Supply Network Planning (SNP), Production Planning/Detailed Scheduling
(PP/DS), Global Available to Promise (ATP), and Transport
Planning/Vehicle Scheduling (TP/VS). Next, requirements like the
following need to be understood:
Characteristic combinations,
or the number of different properties that can describe an object. The
greater the number of characteristics, the greater the CPU load placed
on a system.
The number of key figures that reside in liveCache, which directly impacts the amount of RAM required in the liveCache server.
The number of Demand Planning versions and Supply Network Planning versions,
which are scenarios used in forecasting or simulating demand. Each
version is assumed to consume roughly the same amount of space; more
versions therefore require additional disk space.
Duration of each Planning Run, or how quickly you want to execute your planning run. Faster runs obviously require more CPU processing power.
How often these Planning Runs will be executed; daily, weekly, monthly, and so on.
The number of periods,
measured in weeks. Different types of periods are requested
(historical, retention, planning, and others); each type impacts disk
sizing.
Additional
data related to the number of orders (sales, purchase, planned, and so
on), orders transferred from R/3 to APO, available-to-promise (ATP) and
capable-to-promise (CTP) checks, stock locations, and so on, all of
which primarily impact CPU sizing.
Number of APO users, which also impacts CPU sizing.
In the big scope of
sizing APO, the number of users is really of little consequence, unlike
most of SAP’s other mySAP components.
Sizing mySAP SRM
SAP’s Supplier
Relationship Management offering is much greater than simply
eProcurement, even though its roots are planted squarely in what was
only a few years ago SAP’s business-to-business procurement product
line. As you see in Figure 3,
an SRM solution can be quite complex. The eProcurement product line
alone consists of SAP Enterprise Buyer, Requisite BugsEye, Requisite
eMerge, SAP Business Information Warehouse, and SAP Enterprise Portal.
Like other
mySAP.com components, you must first determine the SRM business
scenario(s) that are to be implemented; each has different required and
optional components, and impact the sizing process accordingly. Other
components come into play, too, enabling core SRM business scenarios,
including SAP R/3, BW, Exchange Infrastructure (XI), SAP Content
Integrator, SAP Supplier Self-Services (for supplier enablement, which
itself requires XI), and the SAP Bidding Engine (which supports
strategic sourcing). All of this, and the following factors, can
complicate mySAP SRM sizing:
As of
version 2.0C, SAP Enterprise Buyer has supported MCOD, which is SAP’s
strategy for supporting multiple mySAP components on one database. As
SAP R/3 4.6C SR2 also supports MCOD, some interesting synergies and
economies can be gained by combining these two normally discrete
databases into one.
Support
for an external catalog (running on Web-based marketplaces or your own
supplier’s site) minimizes hardware required to support catalog hosting
activities, but impacts network activity, not to mention security.
SRM
also integrates well with SAP Enterprise Portal, allowing you to
benefit from single sign-on access to mySAP SRM from the portal, among
other things, but also blurring the line between the two from a sizing
perspective.
Details like the following need to be understood or analyzed with regard to business scenarios that might be implemented:
List all of the business scenarios you intend to implement in your SRM landscape.
Identify
your average document size (for example, the size of your typical
purchase orders), measured in terms of line items created and processed
in your SRM scenario.
Identify
how many procurement transactions will be performed each year, and how
many will specifically be processed in your peak hour.
Characterize
shopping cart details—the creation, display, transfer, and update of a
user’s shopping cart needs to be determined as well as possible.
Identify your total number of trading partners.
Identify
your total expected number of named and concurrent users (where
concurrent users are actively logged into the system and browsing or
otherwise performing work).
Identify auctioning details, including the average number of line items and number of bidders.
Then
leverage a throughput-based sizing model that addresses the processes
to be implemented. A sample process might emulate a workflow commencing
with browsing, then creating a shopping cart, then cutting a purchase
order, then performing contract administration, followed by confirmation
of delivery and subsequent invoicing.
After the specific
business processes are understood, sizing can commence by using the SAP
Quick Sizer to determine SAPS. This data may then be shared with
hardware partners, to be further refined in terms of core CPU, RAM, and
disk requirements for individual servers. The number of servers needed
depends primarily on CPU resource consumption of each business scenario
(other factors are not even considered). Business scenario CPU resource
requirements can be measured and/or estimated if necessary, too.
However, keep in mind that business scenario CPU consumption depends on
the size of your business objects as well as transaction and user-based
loads.
Next, the overall SAP
system landscape can be looked at more closely. SAP AG’s hardware and
other technology partners can recommend the kind and number of servers
that will fulfill the necessary “SAPS” requirements for development,
Test/QA, production, and so on. Security requirements will come into
play, too, as components will almost certainly need to be isolated and
segregated by firewalls. And the need for high availability could easily
require roughly twice the hardware otherwise necessary to satisfy your
online user and transaction loads.
After an SRM system is in place, it’s not unusual to continue the sizing process (at that point called capacity planning),
to refine and tune the system. Java Virtual Machine (JVM) tuning is
common, especially around memory heap and generational Garbage Collector
(GC) tuning. JVM memory tuning can effectively optimize memory usage,
and also increase runtime performance by reducing CPU usage for the
Garbage Collection process. SAP has published an excellent note that
reflects their latest JVM tuning recommendations—see SAP Note 552522: Java Hotspot VM Memory Parameters.
Note that JVM tuning is specific to the operating system—Sun Solaris,
HP-UX, and other operating systems present unique challenges in that
they tend to include system-specific parameters. Tune the number of
threads and number of dbpool connections, for instance, according to
monitored usage.
mySAP Strategic Enterprise Management
Strategic Enterprise
Management relies heavily on SAP BW; a business warehouse acts as the
foundation for SEM functionality. SEM’s analytic application components
rely on multidimensional system-intensive OLAP data structures. Thus,
it’s key to architect and implement a well-performing BW system before
any number of SEM modules can be implemented, including
SEM-BIC, Business Information Collection.
SEM-BPS,
Business Planning and Simulation. SAP AG recommends that SAP Notes
358529, 411725, 407563, and 381022 be reviewed prior to sizing BPS.
SEM-BCS,
Business Consolidation. A rule of thumb for calculating the CPU and
memory needs of BCS users is to perform a user-based R/3 sizing;
multiply the number of expected BCS users by two, and then plug the
result into the SD module.
SEM-CPM, Corporate Performance Monitor.
SEM-SRM, Stakeholder Relationship Management.
The SAP Quick Sizer
supports a combination user/transaction-based approach for sizing the
individual SEM modules, too. For example, data like the maximum number
of concurrent users per group, average number of manipulated data
records, number of steps executed per user per hour, and so on can be
entered.
Sizing the primary OLAP
SEM/BW system, on the other hand, requires converting your expected SEM
users into high, medium, and low BW users. Then, you need to calculate
the data volume of a closing and the complexity of the various SEM
groups (for example, the number of consolidation units, investment
structure, and parallel hierarchies). Finally, to calculate disk space
requirements, multiply the total number of expected SEM records by four
(measured in kilobytes). These can be pretty difficult numbers to
obtain—work hand-in-hand with the BW functional and technical teams to
best position yourself to come even close to accurately sizing SEM.
Interestingly, SAP AG does
not push a three-system landscape for SEM. If standard functionality is
sought, only development and production systems are absolutely
required. However, for consistency within your various mySAP component
landscapes, I still recommend a Test/QA system. And in cases where you
want to test different methods of slicing and dicing the individual SEM
data structures, or provide some level of hands-on training to your
development and super user communities, I highly suggest a business
sandbox as well.
